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Abstract 

Access  control  to  sensitive  information  available  in  pervasive  computing  environments  is  challenging  for 
multiple  reasons:  First,  access  control  must  support  flexible  access  rights  that  include  context-based  con¬ 
straints.  Second,  a  client  requesting  access  to  sensitive  information  might  not  know  which  of  its  access 
rights  are  necessary  in  order  to  be  granted  access  to  the  requested  information.  Third,  pervasive  computing 
environments  consist  of  a  multitude  of  information  services,  which  makes  simple  management  of  access 
rights  essential.  Given  this  setting,  we  discuss  the  shortcomings  of  existing  access  control  schemes  that 
rely  either  on  information  services  encrypting  sensitive  information  before  handing  it  over  to  clients  or  on 
clients  presenting  a  proof  of  access  to  a  service  before  being  granted  access.  To  address  these  shortcomings, 
we  develop  a  solution  based  on  hierarchical  identity-based  encryption.  Namely,  we  present  an  encryption- 
based  access  control  architecture  that  exploits  hierarchical  identity-based  encryption  in  order  to  deal  with 
multiple,  hierarchical  constraints  on  access  rights.  Furthermore,  we  introduce  a  proof -based  access  con¬ 
trol  architecture  that  employs  hierarchical  identity-based  encryption  in  order  to  enable  services  to  inform 
clients  of  the  required  proof  of  access  in  a  covert  way,  without  leaking  information.  We  present  an  example 
implementation  of  our  proposed  schemes  and  discuss  its  performance. 
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1  Introduction 


Whereas  access  control  to  sensitive  information  has  been  well  investigated  for  traditional  distributed  systems 
(e.g.,  file  systems),  there  are  additional  challenges  for  pervasive  computing  environments.  For  example, 
access  rights  need  to  be  more  flexible;  it  should  be  possible  to  issue  access  rights  that  depend  on  a  person’s 
context,  such  as  her  location  or  the  current  time.  In  addition,  there  might  be  covert  access  requirements. 
Namely,  a  client  accessing  some  complex  information  might  not  know  which  of  its  access  rights  are  required 
for  gaining  access.  For  instance,  a  person’s  calendar  entry  reveals  the  location  of  the  people  that  the  person  is 
currently  meeting  with.  In  order  to  be  granted  access  to  this  entry,  a  client  should  at  least  have  access  rights 
to  each  of  these  people’s  location  information.  However,  since  the  client  does  not  know  who  the  person  is 
meeting  with,  it  does  not  know  which  of  its  access  rights  are  required. 

There  are  encryption-based  and  proof-based  access  control  schemes.  In  an  encryption-based  scheme,  a 
service  provides  sensitive  information  to  any  client,  but  only  in  an  encrypted  form.  Only  clients  authorized 
to  access  the  information  have  the  required  decryption  key.  This  approach  is  attractive  for  scenarios  where 
there  are  lots  of  queries  to  a  service  since  it  shields  the  service  from  having  to  run  client-specific  access 
control.  It  is  straightforward  to  add  support  for  covert  access  requirements  to  existing  encryption-based 
schemes  [1,  15,  20,  25,  30].  In  particular,  a  service  encrypts  information  as  usual,  but  it  does  not  tell  a  client 
which  decryption  key  to  use.  Instead,  the  client  needs  to  search  its  set  of  decryption  keys  for  a  matching  key. 
However,  it  is  less  straightforward  to  add  support  for  constraints  on  access  rights  to  the  proposed  schemes, 
especially  when  considering  that  key  management  should  remain  simple. 

In  a  proof-based  access  control  scheme,  a  client  requesting  access  to  sensitive  information  needs  to 
assemble  access  rights  in  a  proof  of  access,  which  demonstrates  to  the  service  that  the  client  is  authorized 
to  access  the  requested  information.  This  approach  is  attractive  for  scenarios  where  flexible,  client- specific 
access  rights  are  required.  A  proof  of  access  prevents  a  service  from  having  to  locate  the  required  access 
rights  itself,  which  can  be  an  expensive  task.  Since  access  rights  are  flexible,  it  is  easy  to  include  support 
for  constraints  in  them.  When  validating  a  proof  of  access,  a  service  must  also  validate  all  the  constraints  on 
the  access  rights  in  the  proof.  However,  it  is  difficult  to  add  support  for  covert  access  requirements  to  proof- 
based  access  control.  Existing  schemes  [2,  17]  assume  that  a  service  can  inform  a  client  of  the  required 
proof  of  access.  However,  in  our  example  mentioned  above,  a  service  informing  a  client  of  the  identity  of 
the  people  that  the  owner  of  the  calendar  entry  is  meeting  with  would  result  in  an  information  leak.  A  naive 
solution  is  to  have  the  client  transmit  a  proof  of  access  for  all  individuals  whose  location  it  can  access.  This 
solution  has  privacy  and  bandwidth  issues:  a  service  can  learn  a  lot  about  a  client,  and  a  client  might  have 
to  transmit  a  lot  of  data.  Therefore,  a  service  must  be  able  to  let  a  client  know  about  the  required  proof  of 
access  in  a  way  such  that  only  authorized  clients  can  learn  about  the  information  being  part  of  this  proof 
description,  otherwise  this  information  will  leak. 

We  present  two  novel  applications  of  hierarchical  identity-based  encryption  that  address  the  above  men¬ 
tioned  shortcomings  of  encryption-based  and  proof -based  schemes  in  the  context  of  pervasive  computing 
environments  (Section  3).  In  identity-based  encryption,  public  keys  are  arbitrary  strings,  which  simpli¬ 
fies  management  of  access  rights  and  constraints.  First,  we  develop  a  hierarchical  identity-based  encryp¬ 
tion  scheme  for  encryption-based  access  control  that  supports  multiple,  hierarchical  constraints  on  access 
rights.  Second,  we  employ  hierarchical  identity-based  encryption  to  implement  covert  access  requirements 
in  proof-based  access  control.  Our  contributions  include  extensions  to  an  existing  hierarchical  identity- 
based  encryption  scheme  to  support  constraints  on  access  rights  and  novel  ways  of  dealing  with  expiration 
of  access  rights  in  identity-based  encryption.  We  have  implemented  our  solutions  in  a  pervasive  computing 
environment  (Section  4).  Finally,  we  provide  an  overall  evaluation  and  discuss  the  relative  strengths  and 
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weaknesses  of  our  example  implementation  (Seetion  5). 


2  Access  Control  to  Information  in  Pervasive  Computing 

In  this  seetion,  we  diseuss  the  eoneepts  of  aeeess  eontrol  and  aeeess  rights  to  information  in  the  eontext  of 
pervasive  eomputing.  We  present  a  list  of  requirements  and  our  threat  model. 

2.1  Overview 

In  pervasive  eomputing  environments,  sueh  as  CMU’s  Aura  [12],  there  are  a  lot  of  services  that  provide 
potentially  sensitive  information  to  clients.  Clients  need  to  have  access  rights  in  order  to  be  granted  aeeess 
to  sensitive  information.  An  aeeess  right  has  an  issuer,  a  reeipient,  an  information  item,  and  a  set  of  eon- 
straints.  For  example,  Aliee  grants  Bob  aeeess  to  her  loeation  information  during  offiee  hours.  Multiple 
serviees  may  offer  the  same  type  of  information  (e.g.,  eell  phone-based  loeation  information,  WiFi-based 
loeation  information,  badge-based  loeation  information,...).  To  simplify  management  of  aeeess  rights,  we 
want  serviee-independent  aeeess  rights,  that  is,  aeeess  rights  should  be  about  information,  not  about  in¬ 
formation  offered  by  a  speeifie  serviee.  For  example,  there  should  be  aeeess  rights  for  Aliee’s  loeation 
information,  not  for  Aliee’s  loeation  information  as  offered  by  her  eell  phone  serviee. 

It  should  be  possible  to  eonstrain  aeeess  rights.  In  this  paper,  we  limit  ourselves  to  eonstraints  whose 
eurrent  value  is  always  available  to  a  elient  (e.g.,  eurrent  time  or  loeation  of  the  elient).  Having  other  types  of 
eonstraints  (e.g.,  loeation  of  the  queried  individual)  requires  more  eomplex  aeeess  eontrol  in  order  to  avoid 
information  leaks,  whieh  is  out  of  the  seope  of  this  paper.  In  addition,  aeeess  rights  should  be  granularity 
aware.  Some  information  (e.g.,  loeation  information)  is  available  at  different  levels  of  granularities  (e.g., 
“CMU”,  “CMU  Wean  Hall”,  “CMU  Wean  Hall  8220”).  Having  an  aeeess  right  for  fine-grained  informa¬ 
tion  should  imply  having  an  aeeess  right  for  eoarse-grained  information.  Granularity-aware  aeeess  rights 
simplify  management  of  aeeess  rights. 

Aeeess  rights  are  managed  by  policymakers.  Typieally,  an  individual  is  the  polieymaker  for  her  own 
personal  information.  Depending  on  the  aeeess  eontrol  seheme,  aeeess  rights  ean  be  represented  in  different 
forms.  For  eneryption-based  aeeess  eontrol,  an  aeeess  right  is  a  deeryption  key,  whereas  for  proof-based 
aeeess  eontrol,  it  typieally  is  a  signed  statement  (i.e.,  a  digital  eertifieate)  issued  by  the  polieymaker.  Re¬ 
gardless  of  the  form,  it  should  be  simple  to  deal  with  aeeess  rights  for  all  involved  entities  (elients,  serviees, 
and  polieymakers). 

We  now  diseuss  how  eneryption-based  and  proof-based  aeeess  eontrol  meet  the  requirements  of  gran¬ 
ularity  awareness  and  eonstraints.  We  also  elaborate  on  some  additional  requirements,  namely,  indistin- 
guishability,  asymmetry,  and  personalization. 

2.2  Encryption-based  Access  Control 

If  there  are  lots  of  requests  for  some  information,  eneryption-based  aeeess  eontrol  is  attraetive  sinee  it  is 
independent  of  the  individual  elients  issuing  these  requests.  For  example,  a  serviee  ean  enerypt  an  infor¬ 
mation  item  onee  and  use  the  eiphertext  for  answering  multiple  requests  asking  for  this  item.  However,  the 
uniform  treatment  of  requests  makes  dealing  with  eonstraints  on  aeeess  rights  and  with  granularity-aware 
aeeess  rights  diffieult.  Covert  aeeess  requirements  and  serviee-independent  aeeess  rights  present  further 
ehallenges.  Let  us  summarize  the  requirements: 

Constraints.  Eaeh  possible  value  of  a  eonstraint  must  require  a  separate  deeryption  key  for  deerypting 
some  enerypted  information  that  should  be  aeeessible  only  under  the  given  eonstraint/value  eombination. 
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For  example,  a  decryption  key  that  allows  a  client  to  access  some  encrypted  information  on  “January  1” 
must  not  allow  decryption  on  “January  2”.  This  requirement  leads  to  an  increase  in  the  number  of  keys.  The 
problem  becomes  worse  when  there  are  multiple  constraints  on  some  access  right.  Luckily,  we  observe  that 
many  constraints  are  of  a  hierarchical  nature.  Therefore,  we  want  a  key  scheme  that  supports  hierarchical 
constraints.  For  example,  given  the  decryption  key  for  “January”,  we  can  derive  the  key  for  “January  1”, 
“January  2”,...  Similarly,  the  key  for  (“January  1”,  “Wean  Hall  8220”)  can  be  derived  from  the  key  for 
(“January,  “Wean  Hall”).  This  feature  can  drastically  simplify  key  management. 

Granularity  awareness.  To  enforce  that  access  rights  to  coarse-grained  information  do  not  grant  access  to 
fine-grained  information,  we  require  separate  decryption  keys  for  the  two  cases.  Similar  to  constraints,  a 
naive  implementation  of  granularity- aware  access  rights  can  lead  to  an  increase  in  the  number  of  keys.  With 
a  hierarchical  key  scheme,  we  can  avoid  this  increase.  In  particular,  the  decryption  key  for  coarse-grained 
information  should  be  derivable  from  the  decryption  key  for  fine-grained  informafion. 

Indistinguishability.  To  implemenf  coverf  access  requiremenfs,  encrypfed  informafion  refurned  by  a  service 
musf  nof  reveal  any  knowledge  abouf  fhe  used  encrypfion  key  or  fhe  required  decryption  key.  Only  a  clienf 
having  fhis  decrypfion  key  should  be  able  fo  gain  fhis  knowledge. 

Asymmetry.  Service-independenf  access  righfs  granf  access  fo  some  informafion  independenf  of  fhe  service 
offering  fhis  informafion.  This  concepf  implies  fhaf  if  mulfiple  services  offer  fhe  same  information,  fhis 
informafion  will  be  decrypfable  wifh  fhe  same  decrypfion  key.  Therefore,  in  a  symmefric  crypfosysfem,  a 
service  encrypting  informafion  would  be  able  fo  access  fhe  same  informafion  offered  by  some  ofher  service. 
For  example,  a  cell  phone  service  offering  Alice’s  cell  phone-based  location  informafion  would  be  able  fo 
access  her  WiFi-based  locafion  information  as  offered  by  some  ofher  service.  We  can  avoid  fhis  problem  by 
using  an  asymmefric  crypfosyslem. 

2.3  Proof-based  Access  Control 

Proof -based  access  control  is  attractive  since  it  offloads  the  assembly  of  the  proof  of  access  to  a  client.  If 
the  client  does  not  know  about  the  required  proof  of  access,  a  service  will  give  it  a  description  of  this  proof. 
However,  when  this  proof  description  contains  sensitive  information,  the  service  must  obscure  the  proof 
description.  Let  us  summarize  the  requirements  for  this  case: 

Indistinguishability.  The  service  must  obscure  the  description  such  that  only  clients  authorized  to  access 
the  sensitive  information  can  learn  about  the  policymaker  responsible  for  this  information  and  the  nature  of 
the  information. 

Granularity  awareness.  Understanding  obscured  proof  description  should  be  granularity  aware:  Being  able 
to  interpret  an  obscured  proof  description  for  fine-grained  information  should  imply  being  able  to  interpret 
an  obscured  proof  description  for  coarse-grained  information. 

Constraints.  Since  access  rights  can  have  constraints  on  them,  these  constraints  should  also  apply  to  a 
client’s  ability  to  interpret  an  obscured  proof  description.  For  example,  when  a  client’s  access  right  for  some 
information  expires,  the  client  should  no  longer  be  able  to  interpret  obscured  proof  descriptions  asking  for  a 
proof  of  access  for  this  information. 

Personalization.  We  want  obscured  proof  descriptions  to  be  personalized  for  a  client.  In  this  way,  if  a  client 
leaked  its  secret  knowledge  required  for  understanding  an  obscured  proof  description  for  some  information, 
other  clients  being  able  to  understand  a  proof  description  for  the  same  information  would  not  be  affected. 
Clients  do  not  have  to  be  malicious  to  leak  their  secret  knowledge;  since  it  has  no  value  for  them  (as  opposed 
to  their  private  key),  they  might  neglect  keeping  it  secret.  (We  do  not  require  personalization  for  encryption- 
based  access  control  since  it  is  is  client  independent  by  design.) 
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Asymmetry.  Based  on  the  same  argument  as  in  the  ease  of  eneryption-based  aeeess  eontrol,  a  serviee 
generating  an  obscured  description  of  the  required  proof  of  access  for  some  information  must  not  be  able  to 
identify  an  obscured  proof  description  for  the  same  information  generated  by  some  other  service. 

2.4  Threat  Model 

In  our  threat  model,  an  attacker  can  corrupt  clients  or  services,  but  not  policymakers.  Corrupted  clients  try  to 
gain  non- authorized  access  to  information  provided  by  a  service,  that  is,  information  to  which  a  client  does 
not  have  any  access  rights.  Corrupted  clients  can  collude.  A  corrupted  service  tries  to  gain  non- authorized 
access  to  information  provided  by  some  other  service,  the  information  can  be  of  the  same  type  as  the  one 
that  it  offers.  Corrupted  services  can  collude.  Attackers  can  also  sniff,  modify,  or  inject  traffic  between 
clients,  services,  and  policymakers.  We  do  not  explicitly  address  denial  of  service  attacks,  though  we  try  to 
limit  load  on  services. 


3  Access  Control  based  on  Hierarchical  Identity-based  Encryption 

We  want  an  access  control  architecture  where  access  rights  are  simple  to  manage,  aware  of  granularity, 
and  constrainable.  In  addition,  the  architecture  has  to  be  asymmetric,  provide  indistinguishability,  and  be 
personalizable  in  the  case  of  proof-based  access  control.  Identity-based  encryption  (IBE)  is  a  good  fit  for 
environments  that  have  these  requirements.  It  is  asymmetric  and  provides  indistinguishability.  Since  public 
keys  are  arbitrary  strings,  key  and  access  right  management  are  simple.  In  addition,  a  hierarchical  version 
of  identity-based  encryption  lends  itself  to  the  implementation  of  hierarchical  constraints  and  granularity 
awareness.  Some  modifications  also  allow  for  the  support  of  personalization.  Therefore,  we  propose  an 
access  control  architecture  for  pervasive  computing  environments  that  is  based  on  hierarchical  identity- 
based  encryption  (HIBE).  In  this  section,  we  review  HIBE  and  discuss  how  we  extend  it  to  build  an  access 
control  architecture  satisfying  our  requirements. 

3.1  Hierarchical  Identity-based  Encryption 

In  an  IBE  scheme,  the  public  key  of  an  individual  is  an  arbitrary  string,  typically  corresponding  to  her  ID 
(e.g.,  her  email  address)  [21].  The  individual  gets  her  private  key  from  a  third  party,  called  a  Private  Key 
Generator  (PKG).  The  third  party  also  provides  additional,  public  parameters  required  for  the  cryptographic 
operations.  Boneh  and  Eranklin  [4]  present  one  of  the  first  practical  IBE  schemes.  Based  on  this  work. 
Gentry  and  Silverberg  [13]  introduce  a  HIBE  scheme.  In  this  scheme,  a  root  PKG  gives  out  private  keys 
to  sub  PKGs,  which  in  turn  give  out  private  keys  to  individuals  in  their  domains  (or  further  sub  PKGs). 
The  public  key  of  an  individual  corresponds  to  the  IDs  associated  with  the  root  PKG,  any  sub  PKGs  on  the 
path  from  the  root  PKG  to  the  individual,  and  the  individual.  Eor  encrypting  messages,  additional  public 
parameters  are  required  only  from  the  root  PKG. 

The  limited  success  of  PKI  has  lead  to  the  development  of  simpler  public  key  infrastructures  (e.g,. 
SPKI  [9]),  that  do  not  require  (hierarchical)  certification  authorities.  In  SPKI,  a  user’s  public  key  is  her 
identity,  and  not  her  name  as  certified  by  an  aufhorify.  In  our  work,  we  pursue  a  similar  approach.  Instead 
of  requiring  fhe  exisfence  of  a  hierarchical  PKG  infraslruclure,  we  lef  each  policymaker  have  ifs  own  PKG. 
The  policymaker  uses  ifs  PKG  for  managing  access  righfs  fo  ifs  informafion.  A  policymaker  can  sef  up 
a  hierarchical  PKG  infraslruclure,  where  if  conlrols  bolh  fhe  roof  PKG  and  any  sub  PKGs.  In  Ihis  way, 
a  policymaker  will  be  able  lo  eslablish  granularily-aware  access  righfs  and  hierarchical  conslrainls  (see 
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Section  3.3).  Boneh  and  Franklin  [4]  also  suggest  a  deployment  scenario  where  individuals  become  PKGs. 
In  the  rest  of  this  paper,  we  refrain  from  talking  about  PKGs  and  use  the  term  “policymaker”  instead. 

Our  architecture  builds  on  the  HIBE  scheme  proposed  by  Gentry  and  Silverberg.  Their  proposed  scheme 
supports  only  a  single  hierarchy  for  a  root  PKG,  which  is  too  limiting  for  our  application  scenarios,  where 
we  might  have  multiple,  hierarchical  constraints  on  some  access  rights.  Therefore,  we  extend  the  scheme  to 
support  multiple  hierarchies. 

A  HIBE  scheme  has  the  advantage  that  it  reduces  the  amount  of  required  storage  and  the  complexity  of 
the  access  right  management.  As  we  will  see  in  Section  3.3,  the  public  key  of  some  information  corresponds 
directly  to  the  identification  string  of  the  information.  There  is  no  need  for  storing  a  separate  public  key 
(obtained  from  a  conventional  cryptosystem  such  as  RSA)  or  some  other  public  value,  as  suggested  in 
earlier  work  [19],  for  each  information  item.  Maintaining  the  mappings  from  some  information  to  a  key  or  a 
public  value  would  also  make  access  right  management  more  difficult.  We  discuss  the  advantages  of  using 
a  HIBE  scheme  in  more  detail  in  Section  3.6. 

3.2  Basic  Operations 

Our  architectures  for  encryption-based  and  proof -based  access  control  each  employ  four  basic,  randomized 
operations.  We  discuss  these  operations  in  this  section  and  their  application  in  encryption-based  and  proof- 
based  access  control  in  the  next  two  sections.  Our  operations  are  based  on  the  operations  introduced  by 
Gentry  and  Silverberg  [13],  we  extend  them  to  support  multiple  hierarchies.  A  detailed  discussion,  giving 
the  exact  cryptographic  steps  for  each  operation,  is  in  Appendix  A.  Eor  readability  reasons,  we  omit  some 
of  the  parameters  of  the  operations  here. 

We  assume  that  all  the  policymakers  agree  on  a  set  of  public  parameters,  params.  We  require  this 
agreement  in  order  to  achieve  indistinguishability.  The  basic  operations  are  Root-Setup{),  Extract{), 
Encrypt{),  and  Decrypt{). 

•  Root.Setup{params)  Qo- 

A  policymaker  runs  this  operation  in  order  to  generate  the  policymaker’s  master  secret.  In  addition, 
the  operation  returns  the  policymaker’s  public  key,  Qq. 

•  Extract{{I Dip, params)  Sip^  withf*  >  1: 

This  operation  returns  the  private  key,  Sip^,  of  a  node  at  level  ti  in  hierarchy  i.  Unless  ti  =  1,  this  key 
is  derived  from  the  private  key  of  the  ancestor  node,  Sip^-l.  If  ti  =  1,  this  operation  needs  to  be  run 
by  a  policymaker,  since  it  requires  its  master  secret.  {IDip, ...,  IDip^)  is  the  sequence  of  node  IDs 
along  the  path  from  the  root  node  of  hierarchy  i  to  the  node  in  question. 

•  Encrypt{{IDip,  ...,  {IDhp, I Dh,th),M,Qo, params)  C: 

After  choosing  a  node  in  each  hierarchy,  a  service  uses  this  operation  to  encrypt  a  message  M  using 
the  nodes’  public  keys.  Eor  each  of  the  h  hierarchies,  the  operation  accepts  a  sequence  of  node  IDs, 
{IDip, ...,  IDip^),  from  the  root  node  to  the  chosen  node.  The  operation  returns  ciphertext  C. 

•  Decrypt{{Sify,  ...,Sh,th):  C, params)  M: 

A  client  uses  this  operation  to  decrypt  ciphertext  C.  The  operation  requires  the  private  key  of  each 
node  chosen  by  the  service  in  its  call  to  Encrypt{)  and  the  ciphertext. 
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1.  Root_Setup() 

2.  Define  hierarehies. 
4.  ExtractO 


5.  Private  keys  of  nodes,  sequences 
of  node  IDs,  and  sub  hierarchies 


3.  Alice’s  public  key 
and  hierarchies 


6.  ExtractO 
10.  Decry pt() 


9.  Encrypted 

Information  EncryptQ 


Figure  1:  Architecture  for  encryption-based  access  control.  Alice  sets  up  her  IBE  scheme  and  hierarchies, 
informs  the  service,  and  grants  access  to  Bob.  Bob  issues  a  query  to  the  service. 


locatioii_fine  2004  always 


location_medium  January  February  office_hours  spare_time 


location_coarse  1  ... 

(a)  (b)  (c) 

Figure  2:  Hierarchies.  Alice  establishes  hierarchies  for  her  location  information  (a)  and  for  each  of  her 
constraints  (b,  c). 


3.3  Encryption-Based  Access  Control 

Figure  1  gives  an  overview  of  the  arehiteeture  for  eneryption-based  aeeess  eontrol,  whieh  eonsists  of  three 
entities:  the  policymaker  managing  access  rights  to  her  personal  information  (“Alice”),  the  client  trying 
to  access  this  information  (“Bob”),  and  the  service  offering  this  information.  In  our  architecture,  we  keep 
key  management  simple  by  using  the  identification  string  of  the  information  as  its  pnblic  key.  To  support 
granularity-aware  access  rights  and  constraints  on  them,  we  let  Alice  define  a  set  of  hierarchies  that  reflect 
the  granularity  properties  of  her  information  and  her  constraints.  We  now  discuss  the  individual  steps  shown 
in  Figure  1  in  detail. 

Setup.  Alice  runs  Root.Setup{)  to  set  up  her  IBE  scheme  (I)  and  to  retrieve  her  public  key.  She  also 
establishes  multiple  hierarchies  (2):  She  first  defines  a  hierarchy  resembling  the  grannlarity  properties  of 
some  information  abont  her  {information  hierarchy).  Figure  2  (a)  gives  an  example  hierarchy  for  location 
information.  The  rnle  for  a  hierarchy  is  that  anyone  who  has  access  to  information  covered  by  a  node  shonld 
also  have  access  to  information  covered  by  a  child  node.  Alice  then  establishes  another  hierarchy  for  each 
of  the  constraints  that  she  wants  to  inclnde  in  her  access  rights  {constraint  hierarchies).  Fignre  2  (b)  shows 
a  hierarchy  that  restricts  the  lifetime  of  an  access  right,  and  Figure  2  (c)  presents  a  hierarchy  for  limiting 
access  based  on  time  of  the  day.  (Non-hierarchical  constraints  are  dealt  with  similarly;  there,  the  hierarchy 
has  only  one  level  and  lists  ah  possible  values.)  Alice  then  informs  the  service  of  her  pnblic  key  and 
her  hierarchies  (3).  Since  none  of  this  information  is  confidential,  there  is  need  only  for  an  authenticated 
channel.  Instead  of  defining  her  own  hierarchies  and  snbmitting  them  to  the  service,  Alice  can  exploit 
predefined  hierarchies  that  the  service  is  already  aware  of.  For  example,  we  expect  that  there  will  be  a 
widely  accepted  hierarchy  for  location  information,  which  is  commonly  used  by  location  services  and  to 
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which  Alice  can  refer. 

Alice  grants  Bob  access  to  some  of  her  information.  In  her  information  hierarchy,  she  chooses  the  node 
corresponding  to  the  information  to  which  she  wants  Bob  to  have  access  (e.g.,  “location_medium”).  She  then 
walks  the  path  from  the  root  node  to  this  node.  In  particular,  she  keeps  a  sequence  of  node  IDs  and,  for  each 
node  on  the  path,  she  calls  Extract{)  with  the  current  sequence  (e.g.,  Extract{{locationJine) , null,  params) 

5i^i  and  £^a;fracf((location_fine,  location_medium),  params)  ^  *S'i,2)  (4).  Ultimately,  this  pro¬ 
cess  will  return  the  private  key  of  the  chosen  node.  Similarly,  for  each  type  of  constraint,  she  picks  the 
appropriate  node  in  the  corresponding  constraint  hierarchy  and  derives  the  private  key  by  repeated  calls  to 
Extract{).  For  each  hierarchy,  Alice  will  end  up  with  a  private  key.  She  then  gives  the  tuple  of  private  keys 
to  Bob,  together  with  the  corresponding  sequences  of  node  IDs  and  the  sub  hierarchies  rooted  in  the  chosen 
nodes  (5).  Transfer  of  the  private  keys  requires  a  secret  channel. 

Given  the  tuple  of  private  keys  and  the  sub  hierarchies  from  Alice,  Bob  can  derive  additional  tuples  of 
private  keys  for  nodes  in  the  sub  hierarchies  by  (repeatedly)  calling  Extract{)  (6).  For  example,  given  the 
private  key  for  (location_fine,  locationjnedium)  and  the  sub  hierarchy  “location_coarse”.  Bob  can  extract 
the  private  key  for  (location_fine,  location_medium,location_coarse) .  It  is  possible  for  Bob  to  delay  this  step 
till  he  receives  encrypted  information  from  a  service  requiring  a  particular  tuple  of  private  keys  derivable  by 
Bob. 

Access  Control.  When  queried  by  Bob  for  information  about  Alice  (7),  the  service  encrypts  the  informa¬ 
tion  (8)  and  returns  the  encrypted  information  to  Bob  (9).  Namely,  the  service  splits  up  the  information  based 
on  its  granularity  properties  and  encrypts  each  piece  separately.  For  example,  the  information  “CMU  Wean 
Hall  8220”  is  split  up  into  “CMU”,  “Wean  Hall”,  and  “8220”.  Then,  for  each  piece,  the  service  locates  the 
node  in  Alice’s  information  hierarchy  that  describes  the  piece  and  gathers  the  IDs  of  all  the  nodes  along  the 
path  from  the  root  node  to  this  node.  In  our  example,  the  ID  sequences  are  (location_fine,  location_medium, 
location_coarse),  (location_fine,  locationjnedium),  and  (location_fine),  respectively.  Similarly,  for  each  of 
the  constraint  hierarchies,  the  service  chooses  the  leaf  node  that  contains  the  current  value  of  the  constraint 
and  gathers  the  IDs  along  the  path  from  the  root  node.  The  service  then  calls  Encrypt{)  with  the  gathered 
sequences  of  node  IDs  (e.g.,  Encrypt{{locationJine,  location_medium,  location_coarse) , 

(2004,  February,  2),  (always,  office Jiours),  “CMU”,  Qo, params)).  Note  that  the  public  keys  used  for  en¬ 
cryption  correspond  directly  to  the  identification  strings  of  nodes.  Bob  decrypts  the  received  ciphertexts 
by  calling  Decrypt{)  with  the  required  tuple  of  private  keys  (10)  for  each  ciphertext.  He  can  decrypt  a 
ciphertext  only  if  the  encrypted  information  is  of  a  granularity  that  he  has  access  to. 

Discussion.  Bob  typically  has  multiple  tuples  of  private  keys,  either  by  deriving  them  or  because  he  has 
been  given  multiple  tuples  by  a  or  multiple  policymakers.  As  explained  in  Section  1,  he  might  not  know 
which  tuple  to  use  for  decryption,  and  the  service  cannot  tell  him  in  order  to  avoid  information  leaks.  In  this 
case.  Bob  has  to  search  his  tuples  till  he  finds  a  fuple  fhaf  allows  successful  decryption.  We  discuss  ways  fo 
limit  the  search  space  in  Section  3.5. 

Our  IBE-based  scheme  fulfills  fhe  requiremenfs  of  being  asymmefric  and  hierarchical  and  supporting 
mulfiple,  hierarchical  consfrainfs.  Using  fhe  idenfificafion  siring  of  some  informalion  or  of  a  conslrainl  di- 
reclly  as  ils  public  key  drastically  simplifies  key  managemenl.  Compared  lo  a  previous  approach  for  dealing 
wifh  expirafion  [4],  which  makes  fhe  currenf  dale  pari  of  fhe  idenfificafion  siring  of  some  information,  our 
approach  does  nof  require  handing  oul  separale  privale  keys  for  each  possible  dale. 

Security  Analysis.  The  security  of  fhe  scheme  is  based  on  fhe  hardness  of  fhe  Bilinear  Diffie-Hellman 
problem.  (Please  refer  lo  Appendix  A  for  delails.)  Given  Ibis  assumption,  Genlry  and  Silverberg  [13] 
show  lhal  Iheir  HIBE  scheme  has  adaplive  chosen  cipherlexl  security  in  fhe  random  oracle  model.  If  is 
slraighlforward  lo  adapl  Iheir  proof  for  multiple  hierarchies.  Therefore,  corrupted  clienls  and  services  and 
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1.  RootJSetupO 

2.  Define  hierarchies. 
4.  Extract( ) 


5.  Private  keys  of  nodes,  sequences 
of  node  IDs,  and  sub  hierarchies 


6.  ExtractO 
10.  DecryptO 


3.  Alice’s  public  key 
and  hierachies 


9.  Challenge 
1 1 .  Proof  ^ 

13.  Information 


8.  Encrypt( ) 

12.  Proof  validation 


Figure  3:  Architecture  for  proof-based  access  control.  The  service  sends  a  challenge  to  Bob.  Upon  resolving 
this  challenge,  Bob  sends  a  proof  of  access  to  the  service. 


traffic  sniffers  cannot  decrypt  encrypted  information  without  having  the  required  decryption  key  or  modify 
encrypted  information.  In  the  case  where  a  client  (or  traffic  sniffer)  does  not  know  which  decryption  key 
to  apply,  we  need  to  ensure  that  the  client  cannot  learn  from  the  ciphertext  which  public  key  of  which 
policymaker  was  used  to  produce  this  ciphertext  (indistinguishability).  Holt  et  al.  [16]  prove  this  property 
for  the  scenario  where  all  the  policymakers  share  the  same  set  of  public  parameters,  as  assumed  in  our 
model. 

Our  scheme  is  not  secure  if  a  client  is  given  access  rights  to  different  types  of  information  by  the  same 
policymaker.  For  example,  for  the  hierarchies  given  in  Figure  2,  assume  that  Bob  has  the  tuple  of  private 
keys  for  ((location_fine),  (2004),  (always)).  In  addition,  Bob  has  access  to  some  information  other  than 
location  information,  for  example,  he  has  the  tuple  of  private  keys  for  ((medical),  (2004,  January),  (always, 
officeJiours)).  This  setup  allows  Bob  to  derive  the  tuple  for  ((medical),  (2004),  (always)).  We  can  fix 
this  problem  by  including  the  ID  of  the  root  node  of  an  information  hierarchy  in  the  root  nodes  of  the 
corresponding  constraint  hierarchies.  For  example,  for  the  constraint  hierarchies  in  Figure  2,  their  root 
nodes  would  become  “2004Jocation_fine”  and  “alwaysJocation_fine”.  This  fix  has  the  drawback  that  it 
makes  key  management  for  the  policymaker  more  difficult.  The  policymaker  can  no  longer  reuse  private 
keys  of  a  constraint  hierarchy  when  it  wants  to  grant  access  to  different  types  of  information  under  the  same 
constraint. 

Our  scheme  is  not  secure  against  collusion.  For  example,  for  the  hierarchies  given  in  Figure  2,  assume 
that  Bob  has  the  tuple  of  private  keys  for  ((locationffine),  (2004),  (always,  officeJiours))  and  that  Carol  has 
the  tuple  for  ((locationffine),  (2004,  January),  (always)).  If  Bob  and  Carol  colluded,  they  could  determine 
the  tuple  for  ((locationffine),  (2004),  (always)).  Yao  et  al.  [28]  propose  a  collision  resistant  HIBE  scheme. 
However,  the  complexity  of  the  EncryptQ  and  Decrypt{)  operations  in  their  scheme  is  0{n'^),  where  n 
is  the  depth  of  a  hierarchy  and  m  is  the  number  of  hierarchies.  As  we  will  see  in  Section  5,  the  complexity 
of  the  operations  in  our  scheme  is  0{mn). 

3.4  Proof-Based  Access  Control 

If  Alice  hands  over  an  access  right  for  some  information  to  Bob,  she  will  also  give  him  a  personalized 
secret.  When  Bob  receives  an  obscured  proof  description  for  this  information  from  a  service,  this  secret 
will  allow  him  to  interpret  the  description.  In  the  rest  of  this  paper,  we  use  the  term  challenge  for  such 
an  obscured  proof  description.  We  keep  management  of  the  challenges  simple  by  using  the  identification 
string  of  some  information  for  generating  a  challenge  for  it.  In  our  architecture,  a  challenge  corresponds 
to  a  ciphertext  and  a  secret  corresponds  to  a  tuple  of  private  keys  enabling  the  decryption  of  ciphertexts. 


To  support  granularity-aware,  constrainable  challenges  and  secrets,  Alice  also  defines  a  set  of  hierarchies. 
The  architecture  for  proof-hased  access  control  is  given  in  Figure  3;  it  is  similar  to  the  architecture  for 
encryption-based  access  control  given  in  Figure  1 .  We  now  review  the  changes. 

Setup.  Alice  defines  an  informafion  hierarchy  and  consfrainf  hierarchies  (2)  and  submifs  fhem  fo  fhe  ser¬ 
vice  (3).  To  allow  Alice  fo  issue  personalized  secrefs  fo  clienfs,  she  could  define  anofher  hierarchy  listing 
all  fhe  clienfs.  However,  as  we  will  see  in  Secfion  5,  fhe  cosf  for  some  of  fhe  crypfographic  operations  is 
proportional  fo  fhe  number  of  hierarchies.  Therefore,  we  refrain  from  infroducing  anofher  hierarchy.  In- 
sfead,  we  have  Alice  personalize  fhe  informafion  hierarchy  by  adding  fhe  idenfify  of  a  clienf  fo  ifs  roof  node. 
For  example,  for  fhe  hierarchy  given  in  Figure  2  (a),  fhe  roof  node  becomes  “localion_fine_Bob.'  Since  fhis 
personalizafion  is  done  in  fhe  same  way  for  each  clienf,  fhere  is  no  need  for  Alice  fo  submil  each  person¬ 
alized  informafion  hierarchy  fo  fhe  service.  To  avoid  collusion  aflacks  befween  clienfs,  Alice  should  also 
personalize  each  of  her  consfrainf  hierarchies. 

When  issuing  an  access  righl  fo  Bob  for  some  informafion  (e.g.,  in  fhe  form  of  a  digilal  cerlificale),  Alice 
also  gives  Bob  a  personalized  secref,  corresponding  fo  fhe  informafion  in  fhe  access  righl  and  limiled  fo  fhe 
same  conslrainfs  (5).  She  generafes  fhis  secref  by  calling  Extract{)  for  fhe  informafion  hierarchy  and  for 
each  of  fhe  consfrainf  hierarchies  (4).  The  luple  of  privafe  keys  relumed  by  Ihese  calls  serve  as  fhe  secref. 
Access  Control.  Bob  issues  a  query  to  the  service  and  fails  to  submit  a  proof  of  access  (7).  Assuming  that 
the  requested  information  requires  covert  access  requirements,  the  service  computes  a  challenge  for  it  (8).  In 
particular,  the  service  calls  Encrypt{)  to  encrypt  a  random  plaintext,  M.  The  public  keys  required  for  this 
operation  come  from  the  information  hierarchy  and  the  constraint  hierarchies  of  the  policymaker  responsible 
for  the  requested  information  (e.g.,  £'ncrypf(  (location_hne_Bob),  (2004Jocation_hne_Bob,  February,  2), 
(always Jocation_tine_Bob,  officeTiours),  M,  Plaintext  M  and  the  obtained  ciphertext,  C, 

serve  as  challenge,  and  the  service  sends  them  to  Bob  (9).  If  the  requested  information  covers  multiple 
individuals,  there  will  be  multiple  challenges.  Sending  a  challenge  to  Bob  requires  only  an  authenticated 
channel,  since  a  challenge  is  personalized  to  a  client  and  useless  to  other  clients  (without  knowing  the 
corresponding  personalized  secret). 

To  resolve  challenge  (M,  C),  Bob  needs  to  find  a  tuple  of  private  keys  that  makes  ciphertext  C  decrypt 
to  plaintext  M.  In  particular.  Bob  calls  Decrypt{)  for  each  of  his  (potentially  derived)  tuples  of  private  keys 
given  to  him  by  Alice  (and  other  policymakers)  (10).  He  stops  when  the  returned  plaintext  is  identical  to 
M.  We  discuss  ways  to  limit  the  search  space  in  Section  3.5.  If  Bob  successfully  resolves  the  challenge(s), 
he  will  resubmit  the  query,  together  with  the  required  proof  of  access  (11).  The  service  will  validate  the 
proof  (12)  and  return  the  requested  information  (13).  Steps  (11)  and  (13)  require  a  secret  channel. 
Discussion.  The  benefits  of  our  scheme  are  secrets  that  are  personalized,  support  constraints,  and  are  gran¬ 
ularity  aware.  Because  the  challenge  for  some  information  is  based  on  the  identification  string  of  the  infor¬ 
mation,  challenges  are  simple  to  manage.  Since  all  the  policymakers  use  the  same  set  of  public  parameters, 
the  challenges  generated  by  a  service  are  indistinguishable. 

A  client  uses  its  secrets  to  resolve  a  challenge  before  submitting  the  required  proof  of  access  to  the 
service.  However,  for  some  scenarios,  this  second  step  can  be  omitted  since  resolving  the  challenge(s) 
already  gives  the  client  all  the  information  it  is  asking  for.  For  example,  if  the  client  asks  for  the  people  in 
a  room,  the  client  will  require  access  to  all  these  people’s  location  information.  The  service  thus  sends  a 
challenge  for  each  person’s  location  information  to  the  client.  After  resolving  these  challenges,  the  client 
knows  all  the  policymakers  in  the  room  and  thus  all  the  originally  requested  information  and  can  skip 
submission  of  a  proof  of  access.  An  obvious  question  is  why  not  skip  this  second  step  all  the  time  and 
stop  using  proofs  of  access?  In  this  model,  the  service  would  encrypt  the  requested  information  instead  of 

*In  the  actual  implementation,  Bob  is  identified  by  his  public  key. 
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a  random  plaintext  (as  suggested  by  Holt  et  al.  [16]).  We  refrain  from  adapting  this  model  beeause,  as  we 
will  see  in  Seetion  5,  espeeially  deeryption  of  information  is  an  expensive  operation.  We  view  eovert  aeeess 
requirements  as  a  speeial  ease.  For  most  queries,  we  expeet  elients  to  know  what  they  need  to  deliver  a  proof 
of  aeeess  for.  Therefore,  we  do  not  plaee  the  burden  of  deerypting  information  on  them  for  every  request  to 
sensitive  information. 

Security  Analysis.  As  mentioned  in  Seetion  3.3,  the  seeurity  of  the  seheme  is  based  on  the  hardness  of 
the  Bilinear  Diffie-Hellman  problem.  (Please  refer  to  Appendix  A  for  details.)  When  ehoosing  a  random 
plaintext,  a  serviee  should  ehoose  it  long  enough  to  make  the  probability  of  the  elient  seeing  a  false  positive 
while  resolving  the  ehallenge  small.  (For  a  plaintext  of  length  I,  the  probability  of  a  false  positive  when 
using  random  tuples  of  private  keys  is  1/2^)  A  false  positive  will  make  the  elient  send  a  wrong  aeeess  right 
to  the  serviee.  If  the  aeeess  right  eontained  private  information,  this  information  would  leak  to  the  serviee. 

Internally,  the  Encrypt{) / Decrypt {)  operations  eompute  a  random  value,  use  it  as  an  exponent  in  a 
modular  exponentiation,  hash  the  resulting  value  into  the  domain  of  the  plaintext,  and  XOR  the  hashed 
value  with  the  plaintext.  In  proof-based  aeeess  eontrol,  instead  of  using  Encrypt{) / DecryptQ  on  a  known, 
random  plaintext,  we  eould  omit  the  XORing  step  and  direetly  use  the  result  of  the  exponentiation  step  as  a 
ehallenge.  This  approaeh  relies  on  the  hardness  of  the  Deeision  Bilinear  Diffie-Hellman  problem.  (Please 
refer  to  Appendix  A  for  details.)  We  ehoose  an  approaeh  based  on  Encrypt() / Decrypt  sinee  it  allows  us  to 
use  the  same  basie  routines  for  both  eneryption-based  and  proof-based  aeeess  eontrol  and  sinee  the  Bilinear 
Diffie-Hellman  problem  is  al  leasl  as  hard  as  Ihe  Deeision  Bilinear  Diffie-Hellman  problem. 

3.5  Limiting  the  Search  Space 

For  coverl  access  requiremenls.  Bob  does  nol  know  which  of  his  (polenlially  derived)  luples  of  privale  keys 
lo  use  for  fhe  DecryptQ  operation,  and  he  has  lo  search  fhrough  his  luples.  We  discuss  some  opfimizalion 
slralegies  in  Ihis  section. 

We  firsl  concenlrale  on  fhe  scenario  where  fhe  challenge  or  fhe  encrypted  informalion  relumed  by  a 
service  cover  a  single  individual  only,  lhal  is.  Bob  needs  lo  find  only  one  luple  of  private  keys.  As  described 
in  Section  3.3,  when  a  policymaker  gives  a  luple  of  private  keys  lo  Bob  granting  him  access  lo  some  infor¬ 
mation  under  some  conslrainls.  Bob  can  potentially  derive  additional  luples  from  Ihis  luple.  We  argue  lhal 
among  Ihe  original  luple  and  Ihe  derived  luples,  al  mosl  one  luple  is  of  relevance  for  Ihe  search.  In  particu¬ 
lar,  since  we  assume  lhal  Bob  is  aware  of  Ihe  currenl  value  of  a  conslrainl.  Bob  knows  which  private  key  is 
relevanl  for  each  conslrainl  hierarchy,  and  he  can  Ihrow  oul  all  Ihe  luples  nol  having  Ihis  private  key  wilhin 
Ihem.  In  practice,  we  expecl  lhal  Bob  can  also  limil  Ihe  search  space  for  Ihe  information  hierarchy.  In  many 
cases,  il  is  safe  for  Ihe  service  lo  inform  Bob  of  Ihe  nalure  and  Ihe  granularity  of  Ihe  information  for  which 
he  needs  lo  resolve  a  challenge,  bul  nol  aboul  Ihe  identity  of  Ihe  policymaker  Ihe  information  is  about  This 
observation  exploils  Ihe  facl  lhal  Ihe  composition  of  mosl  types  of  information  is  well  known.  For  example, 
calendar  information  is  composed  of  fine-grained  location  information  and  activity  information,  bul  nol  of 
medical  information.  Therefore,  when  Bob  asks  Ihe  service  for  calendar  information,  Ihe  service  can  safely 
inform  him  lhal  a  challenge  involves  fine-grained  location  information.  In  summary,  for  all  luples  of  private 
keys  given  lo  Bob  by  a  single  policymaker  and  all  luples  derivable  from  Ihese  luples,  we  expecl  al  mosl  one 
luple  lo  be  relevanl  for  a  search.  In  summary,  Ihe  number  of  luples  lhal  Bob  needs  lo  search  is  al  mosl  one 
per  policymaker. 

If  Ihe  information  relumed  by  a  service  covers  multiple  individuals  (e.g.,  a  service  encrypls  informa¬ 
tion  multiple  times  or  relurns  multiple  challenges).  Bob  will  have  lo  locate  multiple  luples  of  private  keys. 
Therefore,  Bob’s  search  cosl  is  proportional  lo  Ihe  number  of  luples  of  private  keys  given  lo  him  by  policy¬ 
makers  multiplied  by  Ihe  number  of  individuals  covered  by  Ihe  information  relumed  by  Ihe  service.  While 
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this  sounds  expensive,  Bradshaw  et  al.  [5]  present  an  optimization  that  requires  the  client  to  perform  the 
most  expensive  cryptographic  operation  in  this  search  only  once  for  each  tuple  of  private  keys  and  not  for 
each  combination  of  a  tuple  of  private  keys  and  covered  individuals. 

3.6  Discussion 

A  motivation  for  the  design  of  IBE  was  to  simplify  certificate  management  in  email  systems  [21].  For 
example,  IBE  allows  Bob  to  encrypt  email  to  Alice  simply  by  using  her  email  address  as  public  key.  There 
is  no  need  for  Bob  to  contact  Alice  beforehand  to  acquire  a  separate  public  key.  In  our  IBE  scheme,  we 
seem  to  lose  this  advantage:  Alice  needs  to  inform  a  service  of  her  hierarchies  and  her  public  key.  However, 
as  mentioned  in  Section  3.3,  we  do  not  expect  each  policymaker  to  define  its  own  set  of  hierarchies.  Instead, 
there  can  be  a  shared  set  of  hierarchies,  which  a  service  is  aware  of.  In  addition,  we  argue  that  a  setup  step 
is  also  necessary  for  IBE  in  an  email  system:  First,  IBE  schemes  typically  require  a  set  of  public  parameters 
for  encryption.  Bob  must  acquire  these  parameters  before  he  can  encrypt  email  for  Alice.  Second,  Bob 
should  ensure  that  the  email  address  he  is  going  to  use  to  encrypt  sensitive  information  destined  for  Alice 
really  belongs  to  Alice.  He  should  use  this  address  only  if  he  was  given  it  directly  by  Alice  (or  a  trusted 
third  entity)  in  a  setup  step. 

In  our  HIBE  scheme,  the  public  key  of  some  information  corresponds  to  its  identification  string  in  the 
hierarchy.  An  alternative  design  approach  is  to  have  the  policymaker  assign  a  public  key  of  a  conventional 
asymmetric  cryptosystem  (e.g.,  RSA)  to  each  node  in  the  hierarchy.  When  handing  out  the  hierarchy  to 
services,  the  policymaker  also  gives  them  all  the  public  keys  in  the  hierarchy.  Similarly,  when  handing 
out  a  sub  hierarchy  to  clients,  the  policymakers  also  gives  them  all  the  corresponding  private  keys.  This 
approach  has  the  drawback  that  it  increases  the  key  material  that  needs  to  be  stored  and  transferred.  Instead 
of  assigning  a  key  to  each  node  in  a  hierarchy,  Ray  et  al.  [19]  suggest  a  more  sophisticated  scheme  in  which 
the  public  key  of  a  node  can  be  derived  from  the  public  key  of  the  parent  node  and  in  which  the  private  key 
of  a  node  can  be  used  to  decrypt  information  encrypted  with  the  public  key  of  its  child  node.  However,  this 
scheme  (and  similar  algorithms  [1,  15,  25,  20])  still  requires  more  key  material  to  be  stored  and  transferred, 
since  for  each  node,  we  would  have  to  keep  not  only  its  ID,  but  also  an  additional,  public  value  required  by 
the  algorithm.  Moreover,  this  scheme  makes  management  of  access  rights  more  difficult  when  a  policymaker 
uses  a  shared  hierarchy  instead  of  defining  ifs  own.  Namely,  fhe  policymaker  would  still  have  fo  generate 
ifs  own  sef  of  public  values  for  all  fhe  nodes  in  fhe  shared  hierarchy  and  submil  Ihese  values  fo  individual 
informalion  services.  Our  HIBE  scheme  does  nol  require  any  such  public  values  for  each  node. 

The  access  confrol  mechanism  proposed  in  fhis  paper  is  also  suifable  fo  environmenfs  ofher  fhan  perva¬ 
sive  compufing.  In  general,  fhe  mechanism  fargefs  scenarios  where  mulfiple  informalion  services,  run  by 
differenl  organizalions,  need  fo  dislribule  fhe  same  kind  of  informalion  fo  fhe  same  sef  of  clienls.  For  ex¬ 
ample,  anolher  deploymenl  scenario  is  in  fhe  conlexl  of  medical  informalion,  where  mulfiple  hospilals,  run 
by  differenl  HMOs,  need  fo  granl  fhe  same  sef  of  researchers  access  fo  fhe  same  kind  of  sensitive  slafislical 
informalion  galhered  in  a  hospilal. 

As  we  will  see  in  Section  5,  our  proposed  HIBE  scheme  can  be  expensive  in  terms  of  performance. 
This  could  become  a  problem  in  a  pervasive  compufing  environmenl,  where  clienls  mighl  employ  com- 
pulalionally  weak  devices  for  accessing  informalion  (e.g.,  a  cell  phone).  A  common  archileclure  for  such 
environmenfs  is  fo  have  agenls  perform  lasks  on  behalf  of  clienls  [7,  11].  We  could  have  fhis  agenf  decrypf 
informalion  for  ils  client  For  performance  and  availability  reasons,  il  makes  sense  lo  run  Ihis  agenl  on  a 
more  powerful  processing  platform  and  lo  run  only  a  lighlweighl  proxy  on  a  clienTs  personal  device. 
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4  Prototype  Implementation 


The  Aura  ubiquitous  computing  environment  [12]  serves  as  a  testbed  for  the  implementation  and  deployment 
of  our  proposed  access  control  mechanisms.  Because  the  environment  is  mostly  Java,  we  implemented 
our  discussed  HIBE  scheme  in  Java.  In  particular,  we  ported  a  C  implementation  of  IBE  [14]  to  Java 
and  added  support  for  (multiple)  hierarchies.  The  operations  introduced  in  Sections  3.3  and  3.4  require 
expensive  cryptographic  computations.  This  is  especially  troublesome  for  the  Encrypt{)  operation  since  it 
is  performed  by  a  service.  However,  upon  closer  examination  of  this  operation,  we  realize  that  a  service  can 
precompute  most  of  the  expensive  computations.  We  refer  to  Appendix  B  for  details.  We  employ  a  hybrid 
encryption  scheme,  that  is,  we  symmetrically  encrypt  information  with  a  session  key  and  encrypt  only  this 
session  key  with  Encrypt{). 

We  also  implemented  a  few  sample  information  services  that  require  access  control.  There  are  several 
location  services,  each  exploiting  a  different  approach  for  locating  people.  They  can  run  either  proof-based 
access  control  or  encryption-based  access  control.  There  is  also  a  service  that  provides  calendar  information 
and  has  covert  access  requirements.  In  proof-based  access  control,  we  use  SPKI/SDSl  [9]  certificates  for 
expressing  access  rights.  Alice  provides  the  public  parameters  of  her  identity-based  cryptographic  scheme 
and  her  hierarchies  in  SPKl/SDSl  “auto-certificates”  [10],  whose  purpose  is  to  make  information  about 
their  issuer  available  in  an  authentic  way.  Alice  also  uses  auto-certificates  for  handing  out  private  keys. 
Obviously,  recipients  of  such  an  auto-certificate  should  keep  it  secret.  There  is  a  command  line  tool  for 
issuing  certificates,  setting  up  IBE  schemes,  and  extracting  private  keys. 

We  use  the  SSE  protocol  for  communication  between  entities  [24],  which  gives  us  authentication  of  peers 
and  confidentiality  and  integrity  of  the  transmitted  data.  Strictly  speaking,  we  do  not  require  confidentiality 
of  the  (already  encrypted)  information  returned  by  a  service  in  encryption-based  access  control  and  of  a 
challenge  in  proof-based  access  control.  Server  authentication  and  query  confidentiality  and  integrity  are 
required  to  deal  with  attackers  listening,  modifying,  or  injecting  traffic.  Eor  encryption-based  access  confrol, 
we  require  dafa  infegrify  since  our  IBE  implemenfafion  is  only  semanfically  secure,  buf  does  nol  provide 
chosen-cipherfexf  security.  A  similar  argumenf  holds  for  challenges  in  proof-based  access  confrol.  We 
decided  againsf  implemenfing  fhe  required  fealures,  fogefher  wifh  IBE,  in  a  profocol  of  our  own,  since, 
as  history  has  shown,  correcfly  implementing  profocols  is  hard.  SSE  has  been  well  researched,  and  fhe 
overhead  caused  by  fhe  redundanf,  symmefric  encrypfion  is  low.  We  employ  clienf  aulhenficafion  only  for 
proof-based  access  confrol. 

While  nol  being  parf  of  our  Ihreal  model,  a  deployed  system  needs  lo  be  able  lo  deal  wifh  allackers  learn¬ 
ing  privale  keys  or,  worse,  fhe  compromise  of  a  policymaker’s  masler  secrel.  We  can  exploil  mechanisms 
proposed  earlier  [4,  23]  for  Ihis  purpose,  lhal  is,  adding  a  sail  lo  fhe  naming  scheme,  including  a  lime-lo-live 
value  wifh  configurafion  informalion,  and  sloring  secrels  in  a  dislribuled  way. 

5  Evaluation 

In  our  evalualion,  we  concenlrale  on  encryplion-based  access  confrol. We  run  our  experimenls  on  an  un¬ 
loaded  Pentium  lV/2.5  GHz  wifh  1.5  GB  of  memory,  Einux  2.4.20,  and  Java  1.4.2.  An  experimenl  consisls 
of  ten  runs,  we  reporl  bolh  fhe  mean  and  fhe  slandard  devialion  (in  parenlheses). 

We  have  an  Aura  clienf  conlacl  an  Aura  service.  The  service  provides  encrypled  people  location  infor¬ 
malion,  which  is  splil  info  fhree  levels  of  granularily  and  encrypled  using  a  Ihree-level  information  hierarchy. 
There  are  no  conslrainls.  We  look  only  al  fhe  case  where  information  aboul  a  single  individual  is  provided. 
In  addition,  we  assume  lhaf  fhe  clienf  knows  which  decryplion  key  to  use.  If  lakes  1091ms  (42ms)  for  fhe 
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Figure  4:  Performance  of  encryption/decryption.  We  encrypt/decrypt  a  single  message  using  a  variable 
number  of  two-level  hierarchies,  whereas  the  first  hierarchy  has  three  levels.  (Note  that  the  two  graphs  are 
differently  scaled.) 


client  to  retrieve  and  decrypt  the  information.  Let  us  examine  this  cost  in  more  detail.  (Detailed  results  are 
in  Appendix  C.)  For  the  service,  there  is  a  cost  of  25ms  (2ms)  for  an  Encrypt{)  operation  that  exploits  only 
the  root  level  of  a  hierarchy.  (Remember  that  our  service  has  to  perform  three  Encrypt()  operations.)  In 
addition,  there  is  a  cost  of  14ms  (1ms)  per  additional  level  used  in  an  Encrypt{)  operation  (i.e.,  3  *  14ms  in 
our  experiment).  Therefore,  the  overall  cost  of  encryption  is  about  117ms.  The  overall  processing  time  of 
the  service  is  253ms  (31ms);  46%  of  the  cost  is  due  to  encryption.  The  rest  of  the  cost  is  caused  by  fingering 
a  person’s  desktop  computer  in  order  to  locate  her  and  by  (de)marshalling  of  the  request  and  the  response. 
For  the  client,  there  is  a  cost  of  136ms  (2ms)  per  level  used  in  a  Decrypt{)  operation.  Our  client  runs  three 
such  operations,  operating  at  1,  2,  or  3  levels.  Therefore,  the  overall  decryption  cost  is  about  816ms  or  75% 
of  the  overall  processing  time. 

In  our  second  experiment,  we  investigate  the  influence  of  the  number  of  hierarchies  on  processing  time. 
We  encrypt  and  decrypt  a  random  message  using  a  variable  number  of  hierarchies,  whereas  we  exploit  all 
the  levels  in  each  hierarchy.  Similar  to  the  first  experiment,  the  first  hierarchy  has  three  levels.  All  the 
additional  hierarchies  have  two  levels.  Figure  4  presents  the  results.  The  cost  for  encryption  and  decryption 
increases  linearly  with  the  number  of  hierarchies.  This  observation  is  consistent  with  the  characteristics 
of  the  Encrypt{)  and  Decrypt{)  operations  (see  Appendix  C).  Taking  these  characteristics  into  account, 
if  there  are  m  hierarchies  having  rii  levels  (1  <  i  <  m),  the  cost  of  an  Encrypt{)  operation  exploiting 
all  the  levels  in  each  hierarchy  is  25ms  +  —  1)  *  14ms.  For  a  Decrypt()  operation,  the  cost  is 

*  136ms. 

The  performance  numbers  heavily  depend  on  the  underlying  implementation.  Our  implementation  is 
in  Java  and  uses  Java’s  standard  mathematical  package  for  its  cryptographic  routines.  While  we  currently 
do  not  have  a  C-based  implementation  of  HIDE,  there  is  a  more  optimized,  publicly  available  C-based 
implementation  of  standard  IBE  [18].  Since  hierarchical  IBE  exploits  the  same  basic  mathematical  routines 
as  standard  IBE,  we  can  predict  the  performance  of  a  C-based  implementation  of  hierarchical  IBE  based 
on  this  implementation.  Eigure  4  shows  our  predictions.  (More  detailed  results  are  in  Appendix  C).  In 
summary,  the  performance  of  a  C-based,  more  optimized  implementation  would  be  at  least  3.5  (encryption) 
or  4.5  (decryption)  times  better. 

The  presented  results  allow  us  to  judge  the  relative  benefit,  performance-wise,  of  encryption-based  and 
proof-based  access  control.  In  our  implementation  of  proof-based  access  control,  it  takes  a  service  about 
3ms  to  validate  the  1024  bit  RSA  signature  of  a  SPKI/SDSI  certificate.  Assuming  a  single-level  informa- 
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tion  hierarchy  and  no  constraint  hierarchies,  it  takes  the  service  25ms  to  encrypt  a  piece  of  information. 
However,  this  operation  does  not  need  to  be  executed  for  every  client,  the  service  can  reuse  an  encrypted 
piece  of  information  to  answer  requests  from  multiple  clients.  Therefore,  it  pays  off  for  the  service  to  use 
encryption-based  access  control  if  there  are  more  than  8  requests  for  some  information  during  the  lifetime 
of  the  information.  If  there  are  constraints  on  access  rights,  this  number  will  become  correspondingly  larger. 

In  the  case  of  covert  access  requirements,  the  overall  cost  for  proof-based  access  control  will  be  larger 
than  for  encryption-based  access  control.  The  performance  of  the  operations  for  identity-based  encryption 
will  be  similar  for  both  cases.  However,  proof-based  access  control  requires  two  round  trips,  client  authen¬ 
tication,  and  validation  of  the  proof  of  access. 

6  Related  Work 

Identity-based  cryptography  has  been  used  for  different  types  of  applications,  such  as  searchable  audit 
logs  [27]  or  secure  email  and  IPsec  [23].  All  these  applications,  including  our  proposed  one,  exploit 
the  Boneh  and  Franklin  IBE  scheme  [4].  While  there  are  other  schemes  (e.g.,  by  Cocks  [8],  Boneh  and 
Boyen  [3],  Yao  et  al.  [28],  and  Waters  [26]),  we  choose  this  scheme  because  of  the  existence  of  publicly 
available  implementations  [14,  18]. 

There  has  been  previous  work  about  access  control  in  a  hierarchy,  where  information  items  are  classi¬ 
fied  into  partially  ordered  security  classes  depending  on  their  sensitivity  and  users  are  assigned  to  classes 
depending  on  their  clearance.  Each  class  has  an  encryption  (decryption)  key,  which  is  used  for  encrypting 
(decrypting)  information  in  the  class.  Given  the  encryption  (decryption)  key  for  a  class,  it  is  possible  to  de¬ 
rive  the  encryption  (decryption)  key  for  a  class  of  a  lower  security  level.  None  of  the  proposed  hierarchical 
schemes  fulfills  our  requiremenfs  of  asymmefry  and  easy  access  righfs  managemenf:  Akl  and  Taylor  [1], 
Harn  and  Yin  [15],  and  Tzeng  [25]  presenf  symmefric  schemes,  Sandhu  [20]  and  Zheng  ef  al.  [30]  propose 
symmefric  schemes  exploifing  sfrings  for  key  generation,  and  Ray  el  al.  [19]  discuss  an  asymmelric  scheme 
lhal  does  nol  exploil  sfrings  for  key  generalion.  Our  scheme  supporls  only  free-based  and  nol  arbifrary 
hierarchies.  However,  free-based  hierarchies  are  sufficienl  for  expressing  granularily-aware  access  righfs 
and  hierarchical  conslrainls  on  Ihem.  Similar  lo  our  scheme,  Briscoe  [6]  uses  a  hierarchy  for  managing 
lime-based  access. 

Aulomafed  frusl  negolialion  explores  issues  relafed  lo  coverl  access  requiremenfs.  In  particular,  Yu 
and  Winslell  [29]  sludy  Ihe  scenario  where  (parls  of)  a  service’s  access  policy  is  confidenlial.  (An  access 
policy  lisls  Ihe  required  access  righfs.)  The  aulhors  suggesl  Iwo  slralegies,  neilher  of  Ihem  applicable  lo 
our  scenario.  The  firsl  sfrafegy  Iransmils  all  Ihe  clienl’s  access  righfs  lo  a  service,  even  if  Ihey  are  nol 
required.  The  second  one  Iransmils  only  access  righfs  lhal  Ihe  service  asks  for  by  revealing  (parls  of)  ifs 
access  policy.  However,  Ibis  sfrafegy  fails  if  access  righfs  whose  corresponding  access  policy  cannol  be 
revealed  are  required.  In  Holl  el  al.’s  scheme  [16],  a  service  encrypls  informalion  in  a  clienl- specific  way, 
and  Ihe  clienl  needs  lo  find  Ihe  corresponding  decryption  key(s)  in  ifs  sel  of  keys.  Similar  lo  our  scheme, 
Holl  el  al.’s  work  is  based  on  Ihe  Boneh  and  Eranklin  IBE  scheme.  However,  due  lo  reasons  oullined  in 
Section  3.4,  we  do  nol  have  a  service  encrypl  information  for  proof-based  access  conlrol.  Holl  el  al.  do  nol 
investigate  conslrainls  on  access  righls  and  expiration  of  access  righls.  Bradshaw  el  al.  [5]  extend  Holl  el 
al.’s  scheme  lo  supporl  complex  access  policies  expressed  as  monolonic  boolean  functions.  They  apply  a 
secrel  splitting  system  in  order  lo  conceal  Ihe  slruclure  of  such  policies.  Smarl  [22]  also  examines  how  lo 
supporl  complex  access  policies  in  IBE,  bul  he  assumes  lhal  Ihe  policies  are  nol  concealed. 
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7  Conclusions  and  Future  Work 


When  running  access  control  to  sensitive  information  in  a  pervasive  computing  environment,  we  need  to 
be  able  to  deal  with  constraints  on  access  rights  and  avert  information  leaks.  We  showed  how  hierarchical 
identity-based  encryption  can  be  employed  to  address  these  challenges. 

We  implemented  our  proposed  architecture  in  the  context  of  the  Aura  pervasive  computing  environment. 
Our  evaluation  shows  that  identity-based  encryption  is  expensive  (though  the  overhead  can  be  significantly 
lowered  using  a  more  optimized  implementation),  but  it  gives  us  the  convenience  of  being  able  to  use  the 
identification  string  of  some  information  or  of  a  constraint  as  public  key. 

A  weakness  of  our  proposed  architecture  is  that  it  relies  on  all  the  policymakers  agreeing  on  a  set  of 
parameters,  which  could  be  difficult  to  achieve  in  practice.  A  topic  for  further  investigation  is  whether 
we  can  weaken  this  assumption  without  significantly  compromising  on  security.  Another  area  of  future 
research  involves  the  delegation  of  personalized  secrets  used  for  covert  access  requirements  in  proof-based 
access  control:  Whereas  a  recipient  of  an  access  right  can  delegate  this  right  (e.g.,  by  issuing  another  digital 
certificate),  the  recipient  currently  cannot  delegate  the  corresponding  secret,  since  this  delegation  requires 
knowledge  of  the  policymaker’s  master  secret. 
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A  Operations 

In  this  section,  we  describe  the  operations  introduced  in  Section  3  in  detail.  Our  operations  are  based  on 
the  operations  proposed  by  Gentry  and  Silverberg  [13],  we  extend  these  operations  to  support  multiple 
hierarchies.  (We  merge  the  Lower  .Level  .Setup{)  and  Extract{)  operations.)  We  also  assume  that  there 
is  a  global  set  of  public  parameters.  Gentry  and  Silverberg  present  two  encryption  schemes,  a  semantically 
secure  one  and  a  scheme  secure  against  adaptive  chosen  ciphertext  attacks  in  the  random  oracle  model.  For 
presentation  purposes,  we  base  our  discussion  on  the  semantically  secure  scheme.  It  is  straightforward  to 
generalize  our  scheme  to  a  scheme  secure  against  chosen  ciphertext  attacks. 

There  is  a  set  of  public  parameters  params  =  (Gi,  G2,  q,  e,  Pq,  Hy,  H2),  where  Gi  and  G2  are  groups 
of  some  prime  order  q,  e  is  an  admissible  paring:  Gi  x  Gi  ^  G2,  Pq  is  an  arbitrary  generator  of  Gi,  and 
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Hi  and  H2  are  cryptographic  hash  functions  {0, 1}*  ^  Gi  and  G2  ^  {0, 1}"^  for  some  n,  respectively. 
One  of  the  properties  of  an  admissible  pairing  is  bilinearity:  e{aQ,  bR)  =  e{Q,  ii)“^  for  all  Q,  i?  G  Gi  and 
all  a,b  e  Z. 

•  Root.Setup{params)  Qo- 

Choose  a  random  master  secret,  sq  £  and  return  Qq  =  soi^o- 

•  Extract{{IDi^i,...,IDi^ti),Si^ti-i,params)  ^  (Qj,!, with  f*  >  1: 

1.  If  ti  >  1,  pick  random,  secret  Si^a-i  £  Otherwise  Si^  =  sq- 

2.  Compute  Pi^a  =  G  Gi. 

3.  Compute  secret  point  5^,*.  =  +  Si^n-iPi^u  =  Y.%i  {Sip  is  the  identity 

element  of  Gi.) 

4.  Compute  (non-secret)  Qi^j  =  Si for  1  <  J  <  fi  -  1. 

•  Encrypt{{IDi^i,  ■■■,  {IDh^i, IDh^tn)^  M,Qo,params)  C: 

1.  Compute  Pij  =  Hi{IDi^i, IDij)  G  Gi  for  1  <  j  <  fi  and  1  <i  <  h. 

2.  Choose  a  random  r  G  Z/gZ. 

3.  Set  the  ciphertext  to  be: 

C  =  [rPii,  (rPi,2, ...{rPh,2,  ...,rPh^t^) ©  i?2(/)] 

where 

h 

9  =  o((50) -Pi,!)  G  G2. 

i=l 

•  Decrypt{{Sify, Sh,th),  •••,  Qi.ti-i),  •••,  {Qh,i,  ..■,Qh,th-i),C,params)  M: 

Let  C  =  [Uq,  {Ui^2,  ■■■,  Ui^ti),  •••,  {Uh,2:  •••)  Uh,th)^  bo  the  ciphertext  encrypted  using  the  sequences 
of  IDs  (/Dip, /Dipi), {I  IDh,th)-  To  decrypt  C,  compute 

Y[KUo,s,,u) 

V  ©  H2i^^ - )  =  M. 

n  n  KQi,j-i,Uid) 

i=l j=2 

The  security  of  the  scheme  is  based  on  the  hardness  of  the  Bilinear  Diffie-Hellman  problem:  Given  a 
randomly  chosen  P  G  Gi,  as  well  as  aP,  bP,  and  cP  (for  unknown  randomly  chosen  a,b,c  G  Z/gZ), 
compute  e{P,  For  proving  security  of  our  scheme  in  the  random  oracle  model,  we  have  to  modify 

Gentry  and  Silverberg’s  proof  (Appendix  A.3  of  [13]).  This  modification  is  straightforward,  it  exploits  the 
same  ideas  that  we  have  exploited  for  extending  Gentry  and  Silverberg’s  scheme.  We  give  only  an  outline 
of  the  modifications  here:  There  needs  to  be  a  separate  for  each  hierarchy,  and  the  challenge  operation 
needs  to  take  the  additional  hierarchies  into  account.  For  the  latter  modification,  we  rely  on  the  symmetry 
of  e. 

The  alternative  solution  for  proof -based  access  control  suggested  in  Section  3.4  relies  on  the  hardness  of 
the  Decision  Bilinear  Diffie-Hellman  problem:  Given  a  randomly  chosen  Z’  G  Gi,  as  well  as  aP,  bP,  cP, 
and  r  (for  some  a,  b,c,r  G  'LjqL),  refurn  true  if  r  =  e(P, 
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Operation 

Java 
y  (a) 

h 

C 

(cr) 

T  P'  ■ 

14 

(1) 

4 

(0) 

Exponentiation 

11 

(1) 

2 

(0) 

Pairing 

136 

(2) 

29 

(0) 

Table  1:  Processing  times.  Mean  and  standard  deviation  of  elapsed  time  for  expensive  cryptographic  oper¬ 
ations  in  our  Java-based  implementation  and  in  MIRACL’s  C-based  implementation  [18]  [ms]. 

B  Optimizations 

In  this  section,  we  discuss  a  few  optimizations  that  we  apply  in  our  implementation  of  the  operations  outlined 
in  Appendix  A.  We  concentrate  on  encryption-based  access  control,  the  argument  is  similar  for  proof-based 
access  control. 

Encrypt  {)  is  a  time-critical  operation  since  it  is  run  by  a  service.  To  speed  up  this  operation,  a  service 
can  precompute  the  Pij  in  step  1  and  the  pairings  in  step  3.  In  addition,  the  service  can  precompute  sliding 
windows  for  multiplications  on  Pij  and  use  them  for  the  computation  of  rPij. 

C  Evaluation 

Our  Java-based  implementation,  which  is  based  on  a  C  implementation  [14],  exploits  Tate  pairings  over 
super-singular  elliptic  curves.  We  use  a  160  bit  prime  for  q  and  a  512  bit  prime  for  p,  where  Gi  is  an 
order-g  subgroup  of  E(¥p)  and  G2  is  an  order-g  subgroup  of  Fp2.  For  the  configuration  given  in  Section  5, 
the  performance  of  the  expensive  cryptographic  operations  is  given  in  Table  1.  For  the  C-based  implemen¬ 
tation  [18],  we  use  the  same  set  of  parameters  and  configuration  as  for  the  Java-based  version  (gee  3.2.3 
instead  of  Java  1.4.2). 
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